Most information technology and in particular hardware is tailored to meet the needs of imperative language based code. This is due to the serial nature of classic processors and the stepwise iterative approach to execution of commands and manipulation of data in an imperative language based program.
Functional programming languages (FPs) are typified by a particular style of programming which focuses upon the function as the central building block of its functionality. Each function is seen as having an input and as generating an output. A pure functional language has no side effects, changes no state variables and is merely a function of starting parameters which may be other functions. The result of a routine is an output which is independent of when and where in the code of the routine is run. This lends to such properties as modularity, parallelism, and referential transparency among others.
Functional programming language based programs are more capable in terms of possible inherent parallel functioning on machines running FP code. Typical current implementations of FP code, on a classic processor and in classic processing platforms, are carried out by mimicking parallelism by running the small parts of the parallel FP processes interleaved in time on the processor. An FP application is often run as a virtual machine on top of a single processor in a classic processing platform.
An example of a classic processing platform in which an FP application operates is presented in FIG. 1.
A virtual machine 100 operates on top of a processor 150 having registers 152. The virtual machine 100 operates an FP application which comprises a number of processes including a garbage collector 120. The remaining functionality of the FP application is shown as an FP process 110. The garbage collector 120 is a necessary part of any functional program which serves to remove any unused objects in memory. The garbage collector 120 and the FP process 110 have virtualized access 125 to resources of the processor 150 including its registers 152. Both the FP process 110 and the garbage collector 120 are coupled over a memory bus 145 to a program 172, a heap 174, a first stack 176, and a second stack 178 of a memory 170.
In terms of function, both the FP process 110 and the garbage collector 120 share both processor 150 time (and hence share access to the registers 152), bus 145 resources, and memory 170 access. This is an inefficient way of executing parallel processes, which becomes increasingly inefficient as the number of simulated parallel processes increases. Each parallel process requires access 125 to processor 150 time, bus 145 resources, and access to the program 172, the heap 174, and the stacks 176, 178 stored in memory 170. As such each process is provided, one at a time, a finite time slice during which it may use said processor time, bus resources, and memory access. Moreover, the prior art processing platforms of FIG. 1 often results in extremely variable execution times which can depend upon memory usage.